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RELATIONSHIP MANAGEMENT SYSTEM DETERMINING CONTACT 
PATHWAYS IN A CONTACT RELATIONAL DATABASE 

Cross Reference to Related Applications 

[0001] This application is a continuation-in-part of U.S. Patent Application Serial 
No. 09/455,877, entitled a "Relationship Management System That Provides an 
Indication of Users Having a Relationship With a Specified Contact", filed December 
6, 1999, and also is a non-provisional application claiming priority from U.S. 
Provisional Patent Application Serial No. 60/414,701 entitled a "Relationship 
Management System Determining Contact Pathways in a Contact Relational 
Database," filed September 30, 2002, which are both incorporated herein by reference 
in their entirety. 

Background 

[0002] The present invention relates generally to relationship management systems 
and, more particularly, to a relationship management system that determines a set of 
users having a relationship of some kind with a specified contact and/or a user 
associated with the relationship management system. 

[0003] Relationship management systems typically use one or more relational 
databases to, for example, store data or information pertaining to contacts, which may 
be individual persons, corporations, etc. The information stored in the database for 
any particular contact may include, for example, phone numbers, facsimile numbers, 
post office addresses, electronic-mail (e-mail) addresses, etc. and this information 
may be used to produce mailing lists and customer lists, to send facsimiles, e-mails, or 
to store contact information to be retrieved at any desired time. One of the simplest 
and most common uses of a relationship management system is as a centralized 
electronic address book that can be used by any number of individuals or groups 
within, for example, a corporation, a law firm, etc. for any number of reasons, such as 
keeping track of contact information, making sales calls, sending letters, facsimiles, e- 
mails, etc. 

[0004] At least one known relationship management system stores each of the 
different types of contact information (such as names, post office, street or e-mail 
addresses, facsimile and phone numbers, company affiliations, titles, etc.) in a 
database only once and uses folders to provide access to the stored contact 
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information to any number of the users of the relationship management system. Each 
contact stored within the database may be referenced by any number of folders and 
each folder typically has access rights that define one or more users of the relationship 
management system that can access the folder and, thereby, access the contact 
information associated with the contacts referenced by the folder. There may be 
different types of folders, such as private or personal folders in which personal 
contacts, business contacts, etc. are referenced, business folders, group folders set up 
for specific groups of users, task folders set up for specific tasks, etc. A user may 
add, change or delete the contact information for any of the contacts within the folders 
to which the user has access and may add new contacts and associated contact 
information to the database by adding a new contact to the folder. Each folder may 
reference more than one contact and each contact may be referenced by more than one 
folder. Thus, for example, if two users know the same person (a contact), the 
personal or private folders for each of these users may reference that contact and, 
thus, each of these users may have access to the contact information associated with 
that contact, even though the contact information for that contact is stored only once 
in the database. 

[0005] The knowledge of which members of a set of users of a relationship 
management system know a particular person and how the users know that particular 
person may be helpful in making presentations to that particular person, performing 
sales activities in which that particular person is involved, conducting research about 
the particular person or a corporation at which the particular person works, etc. Thus, 
it can be helpful for one user of a relationship management system to find out which 
of the other users of that system (who typically work for or are affiliated with the 
same company or organization) know a particular person or contact. The knowledge 
of which users of a relationship management system have a relationship of some kind 
with a particular person or contact stored in the relationship management system is 
referred to herein as user-contact reference information. 

[0006] In the past, relationship management systems, while allowing users to 
access contact information about contacts stored within the database associated with 
the relationship management system, did not provide any user with the ability to 
determine, quickly and accurately, which of the other users of the system knew or had 
a relationship of some kind with a particular contact. In fact, in the past, information 
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about which users of the system knew which contacts had to be manually entered into 
the database system as a separate list. Because this list of user-contact reference 
information changes each time a contact is added to a folder or is deleted from a 
folder within the database, the user-contact reference list had to be constantly updated, 
which was tedious, time consuming and prone to data entering errors. Furthermore, 
the updating of the user-contact reference list was typically given a low priority and, 
thus, the information within this list was frequently out of date. Likewise, these 
manually created lists did not provide any information on the type of relationship 
between the contact and the user referencing the contact, such as how these people 
knew each other or how they met, what specific type of relationship exists, such as a 
business or personal relationship, or the strength of the relationship. 

Summary 

[0007] According to one disclosed embodiment, a relationship management system 
comprises a database storage routine stored on a computer readable medium and 
adapted to store, within a database, contact information for one or more contacts, an 
indication of one or more contacts referenced by one or more folders, and a set of 
contact-folder pairs, wherein each contact-folder pair includes a contact indication 
that indicates one of the contacts and a folder indication that indicates one of the 
folders. The reference routine searches the contact indications of the contact-folder 
pairs for the specified contact to locate at least one contact- folder pair associated with 
the specified contact. The reference routine also determines one of the users that 
knows the specified contact from the folder indication of the one of the contact-folder 
pairs as a user having access rights to the folder specified by the folder indication of 
the one of the contact-folder pairs. 

[0008] The relationship management system also has a reference routine adapted to 
be executed by a processor to access the database to determine which of the users of 
the relationship management system knows a specified contact. A display routine is 
stored by the computer readable medium and adapted to be executed on the processor 
to display an indication of the determined users that know the specified contact. 

[0009] According to another disclosed example, a relationship management system 
is configured to be used with a processor, a display device and a database to store 
contact information defining a set of contact individuals associated with each of a 
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plurality of users of the database. The system includes a computer readable medium 
and an input routine stored on the computer readable medium that is adapted to be 
executed on the processor to accept a designation of a target individual from a starting 
person. A contact information access routine stored on the computer readable 
medium and adapted to be executed on the processor accesses contact information in 
the form of user-contact pairs stored in the database that are associated with at least 
one of the starting person and the target individual. A relationship pathway 
determination routine is further stored on the computer readable medium and adapted 
to be executed on the processor to utilize the user-contact pairs accessed by the 
contact information access routine and to determine at least one relationship pathway 
that links relationships between the starting person and the target individual such that 
any two adjacent entities in the relationship pathway comprise one of the user-contact 
pairs. A display routine is stored on the computer readable medium and is configured 
to be executed on the processor to display an indication of the relationship pathway on 
the display device. 

Brief Description of the Drawings 

[0010] Fig. 1 is a block diagram of an information system network on which a 
relationship management system may be implemented. 

[0011] Fig. 2 is an example screen display used in a relationship management 
system to enable a user to reference contact information for one or more contacts 
stored in a database and to use a user-contact reference routine to determine which 
users of the relationship management system have a relationship with a specified 
contact. 

[0012] Fig. 3 is an example screen display illustrating a list specifying which users 
have relationships with a specified contact and some information about the nature of 
these relationships. 

[0013] Fig. 4 is a block diagram of a join table stored in a database associated with 
a relationship management system which stores contact- folder pair information and 
which may be used to generate the display of Fig. 3. 

[0014] Fig. 5 is a block diagram of a table stored in a database associated with a 
relationship management system which stores user-contact pair information and 
which may be used to generate the display of Fig. 3. 
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[0015] Fig. 6 is a depiction of an example folder table illustrating some exemplary 
attributes of each folder stored in a database associated with a relationship 
management system. 

[0016] Fig. 7 is a depiction of an example join table illustrating some exemplary 
attributes of each of a set of contact- folder pairs stored in a database associated with a 
relationship management system. 

[0017] Fig. 8 is an example screen display used in a relationship management 
system to enable a user to request a determination of relationship pathways to an 
entered target individual reference stored in a database. 

[0018] Figs. 9A-9C are diagrams illustrating varying degrees of user-contact 
information for users of a relationship management system that is used to determine 
respective varying degrees of determined relationship pathways. 

[0019] Fig. 10A is an example screen display illustrating a prioritized list 
specifying relationship pathways determined in a relationship management system 
between a starting person and a target individual along with information about the 
relative strengths of the determined relationship pathways. 

[0020] Fig. 10B is an example screen display illustrating an expanded view of the 
prioritized list illustrated in Fig. 10A. 

[0021] Fig. 1 1 is an illustration of the operation of a weighting routine that may be 
used to determine quantitative weights of relationship pathways determined in a 
relationship management system. 

[0022] Fig. 12 is an illustration of the operation of a prioritization routine that may 
be used to determine priority among multiple relationship pathways determined in a 
relationship management system. 

[0023] Fig. 13 is a flow diagram of a procedure that may be used to determine 
relationship pathways in a relationship management system. 

[0024] Fig. 14 is a flow diagram of a procedure that may be used to retrieve user- 
contact pairs of a starting person. 

[0025] Fig. 1 5 is a flow diagram of a procedure that may be used to retrieve user- 
contact pairs of a target person. 
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[0026] Fig. 16 is a flow diagram of a procedure that may be used to plot 
relationship pathways, which procedure may be used by the relationship pathway flow 
diagram of Fig. 13. 

Detailed Description 

[0027] Referring to Fig. 1 , an information system 100 on which a relationship 
management system can be implemented is illustrated. The information system 100 
includes a number of workstations or user interfaces 102, each having an associated 
processor 104 and memory 106 storing a relationship management routine 1 10 
including numerous routines therein. The workstations 102 are interconnected to a 
database 1 12 via a communication link 1 14 which may be, for example, a local area 
network (LAN) link. The information system 100 may include any desired number of 
user interfaces 102 and each of the user interfaces 102 may include any desired type 
of computer or processor that uses any operating system such as the Microsoft 
Windows® operating system, a UNIX operating system, etc. to execute programs or 
applications. Likewise, the database 112 may be any suitable or desired type of 
database with an associated database server (not shown) which may be, for example, a 
Microsoft SQL database server, an Oracle database server, etc. While the database 
1 12 is illustrated as being a stand-alone unit, the database 1 12 could be integrated into 
one of the user interfaces 102, if so desired. Still further, the communication link 1 14 
may be any desired type of LAN connection such as a Microsoft NT or a Novel 
Netware, or may be any other desired type of communication network. While the 
implementation of the communication link 1 14 as a LAN preferably uses a TCP/IP 
protocol, any other communication protocol may be used as well to provide 
communications between the user interfaces 102 and the database 112. 

[0028] Generally, the database 1 12 stores information about any number of 
contacts, which may be persons, corporations or other entities. The database 1 12 may 
store different types of contact information, such as name and title information, post 
office, street and electronic address information, phone number and facsimile number 
information, the nature or type of contact (e.g., personal or business), business 
affiliations (e.g., work or worked at the same company), organization affiliations (e.g., 
support same charitable organization), educational affiliations (e.g., attended the same 
college), strength ratings of the relationship between the user and the contact, etc. for 
each contact in different contact information tables. Further, the database 112 stores 
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indications of folders and each folder includes a reference to zero, one or more of the 
contacts within the database 1 12. Each folder has access rights enabling one or more 
particular users of the relationship management routine 1 10 to use the folder. The 
user having access rights to a folder can view or otherwise access information 
pertaining to the contacts referenced by that folder. Thus, the user having access to a 
folder can place a contact within the folder (i.e., can reference a contact using the 
folder) and can store and retrieve contact information from the contact information 
tables within the database 112 pertaining to the contact referenced by the folder. A 
folder can be a private or personal folder, in which case the folder is "owned" by an 
individual and can be used to store, for example, personal, business and other contact 
information for that individual. Alternatively, a folder can be a group folder used by a 
group of users, for example, to reference contacts making up a mailing list, a 
customer list, etc., to reference contacts associated with a particular project, such as a 
business deal that is in progress, to reference contacts having some common 
characteristic, such as lawyers, doctors, etc. or can be a folder created for any other 
purpose or activity. Of course, folders may be used in any other manner to reference 
contacts of any desired nature and folders may be accessible by one or more users. 
As used herein, the term folder refers to any programming construct that enables 
certain contact information to be visible to one or more particular users of a 
relationship management system. 

[0029] As illustrated for one of the user interfaces 102 in Fig. 1, each of the 
interfaces 102 includes a number of routines within the relationship management 
routine 1 10, as mentioned previously, that are executable by the processor 104. The 
routines include a database access routine 1 16 that communicates with the database 
1 12 and accesses data within the database 1 12 using any desired type of 
communication layer. The database access routine 116, if desired, may use a database 
driver, such as the Microsoft DB-LIB driver, to perform communications with the 
database 112. Also included is a display routine 1 1 8 that, as is typical in relationship 
management systems, creates user interface screens for display on a display screen or 
other display device associated with the user interface 102 to enable communication 
with the user via the user interface 102. The routines 1 16 and 1 18 operate together to 
enable a user to enter information, such as contact information related to persons or 
corporations or other entities to be stored in the database 1 12, to delete information 



- 7 - 



Patent 

Atty. Docket No. 29516/38346 

from the database 1 12, to access information stored in the database 1 12, etc. The user 
may also use the routines 1 16 and 1 18 to perform functions using contact information 
stored in the database 112, such as to send e-mails, facsimiles or regular mail, to 
create mailing lists, customer lists, etc. The display device, referred to above, may 
include not only a computer screen, but may be devices such as a printer, audio 
devices, etc. that communicate information to be output to the user. 
[0030] In order to effect an automated determination of relationship pathways, a 
further use of the database access routine 1 16 may be to input or designate a named 
target individual that the user or a starting person desires to meet. This further 
function of the routine 1 16 is used to initiate a determination of actual or potential 
relationship connections or pathways between the starting person and a target person 
through other routines of the system 1 10 that are stored in memory 106 (and to be 
discussed below). This functionality essentially determines persons within the 
database who know or may know both the starting and target individuals or a string of 
people who know each other and can form a link between the starting person and the 
target person. 

[0031] Further serving to effect the functionality of determining relationship 
pathways within the relationship management system 1 10 illustrated in Fig. 1, a user- 
contact reference routine 120, which is stored in the memory 106, accesses the 
database 1 12 to determine which users of the relationship management system know 
(i.e., have a relationship of some kind with) the designated target person, as well as 
those who know the starting person, who may or may not be the specifying user. This 
routine 120 accesses the relationships as user-contact pairs. One example of such 
user-contact pairs is where one person of the pair is a user of the relationship 
management system and the other person is a contact person stored in the user's 
contact list or folder. Another example includes a pairing where one person is the 
target person and the other person is a user of the database who either has or may 
have a relationship with the target person. Additionally, as will be explained later, the 
routine 120 may also access intermediate user-contact pairs for determining further 
relationship pathways. 

[0032] Other methods of storing and determining relationships between users and 
contacts using tables in the database 1 12 may be used as well to enable the user- 
contact routine 120 to determine which users have a relationship of some kind with 
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any particular contact. The user-contact routine 120, as described herein, enables the 
relationships between users of the relationship management system and any particular 
contact stored in the database associated with the system to be determined quickly and 
accurately because this information is automatically stored, created or deleted when a 
user references a contact or deletes a contact from a folder or otherwise indicates a 
relationship with a contact. Furthermore, because the relationship information is 
stored in and determined from tables, such as those used to perform other functions 
within the relationship management system, no one has to manually enter or update a 
user-contact reference list, which makes the relationship information determined by 
the user-contact reference routine 120 described herein more accurate and reliable. 
Still further, an opt-in flag enables a user to hide the fact that the user has a 
relationship with a particular contact, assuring privacy where needed or desired. 
Likewise, the relationship description, type and strength or other relationship 
description fields provide a user with more information about the relationships 
between users and any specified contact than that provided by a manually created list 
of user-contact relationships typically associated with known systems. 

[0033] In order to determine relationship pathways, the relationship management 
system 1 10 also includes a relationship pathway determination routine 122. This 
routine 122 utilizes the user-contact pair information garnered by the user-contact 
reference routine 120 to determine or plot specific relationship pathways or 
connections that may found among the user-contact pairs. As an example of how 
routines 120 and 122 work together, it is assumed that a user of the database (e.g., "Ed 
Roberts"), who is, in this case, the "starting person", desires to find a relationship 
connection to a target person. The routine 120 first searches the database 1 12 for 
user-contact pairs including the user. In other words, the routine 120 will access Ed 
Robert's folder of contacts to determine the identity of his contacts. Additionally, the 
routine 120 searches the database 1 12 for user-contact pairs having the target person 
as a contact. That is, the routine 120 determines all users of the database having the 
target person as a contact. Once this information is obtained, the relationship pathway 
determination routine 122 will plot relationship pathways, connections or 
intersections between the two groups of user-contact pairs. If no intersections are 
found or further degrees of relationships linkings are desired, the routine 120 may 
again be called to obtain further intermediate user-contact pairs including user-contact 
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pairs for contact individuals in Ed Robert's folder, as well as user-contact pairs for the 
users having the target person as a contact. The relationship pathway determination 
routine 122 will then plot further pathways between the starting person and the target 
person by finding intersecting intermediate user-contact pairs. 

[0034] Referring now to Fig. 2, a screen display 1 30 which may be created by the 
routine 118 to display the contents of a folder, in this case, Ed Roberts' private folder, 
is illustrated. The screen display 130 includes a browser section 132 illustrating the 
folders to which the user (in this case, presumably Ed Roberts or someone else having 
access to Ed Roberts' private folder) has access. These folders are illustrated as firm 
resources folders, mailing list folders, marketing event folders, matter folders, practice 
group folders, private folders, and public folders. Of course, these folder names and 
types are used as examples only and other types or kinds of folders could also exist 
within the database 112. In any event, the Ed Roberts' private folder is illustrated in a 
folder view 134 which includes a list of contacts referenced by Ed Roberts' private 
folder. As illustrated in Fig. 2, a number of personal contacts including Jose 
Simental, John Smith, etc. as well as a number of corporate contacts, including Tele- 
Communications Incorporated, TeleNorth Financial Services, etc. are listed or are 
referenced by Ed Roberts' private folder. Of course, contacts, such as personal 
contacts, may have associated companies which may be other contacts stored within 
the database 1 12. Thus, John Smith is associated with Union Chemicals, Inc., as 
illustrated in the folder view 134. 

[0035] Still further, particular contact information may be displayed about a 
selected one of the contacts (illustrated as Jane Tarnoff in the display screen 130). As 
illustrated in a contact information view 136, the business association, address, two 
business phone numbers, a facsimile number, an e-mail address, and a web site 
address for Jane Tarnoff are illustrated as the contact information stored for the 
contact Jane Tarnoff within the database 1 12. Of course, as indicated above, the 
different types of contact information for Jane Tarnoff (or any other contact) are 
stored in different tables within the database 1 12 and this information, as stored in the 
contact information tables, reference the contact ID for Jane Tarnoff (or some other 
contact ID). The different information related to each type of contact information 
may be stored in different fields of the contact information tables. Thus, for example, 
the table for post office address information may include fields for title information, 
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street location, city, state and zip code information. The table for phone numbers may 
include a type (such as business, home, alternate business, etc.) field, a nature field, 
such as whether the number is a phone number or a facsimile number (illustrated as 
icons in the contact information view 136), a number field, and a description field. 
This information is displayed in different portions of the contact information view 136 
of Fig. 2. 

[0036] Still further, as illustrated in Fig. 2, the contact information view 136 
includes an opt-in box 138 which is used by the user-contact reference routine 120. 
The opt-in box 138 may be selected by checking (or not checking) the box 138 which 
sets or does not set an opt-in flag in a field within the database 1 12, to be described 
hereinafter. Similarly, the contact information view 136 includes a relationship 
description section 140 in which the user (in this case any user having access to Ed 
Roberts' private folder) can place a description of the relationship between the user 
(to which the folder belongs) and the contact. The text entered into the description 
section 140 is also stored in a field in the database 1 12 as described hereinafter. Of 
course, other types of relationship description information may also be entered by the 
user. For example, a simple description of the nature or type of relationship may be 
chosen from a predetermined set of descriptions, such as whether the relationship is a 
business, personal, social, family, etc. relationship. Alternatively or in addition, an 
indication of the strength of the relationship, such as a number ranging from one to 
ten with ten being a very strong relationship and one being a very weak relationship 
(as in, the user barely knows the contact) may be entered by the user. 

[0037] It will be understood that the other folders which reference the Jane Tamoff 
contact, especially other private folders, will have similar opt-in and description fields 
to be used to describe the relationship which these other users have with Jane Tamoff. 
Likewise, any of the other contacts referenced by Ed Roberts' folder may provide 
similar opt-in and description fields to enable the relationships between Ed Roberts 
and these other contacts to be discovered and described by the user-contact reference 
routine 120. 

[0038] In any event, when a user, such as the user viewing the Ed Roberts' folder 
wants to find out which other users know or have some relationship with a contact, in 
this case, Jane Tarnoff, the user can select the Who-Knows-Who™ feature 142 which 
causes the system 100 to implement the user-contact reference routine 120 which 
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searches the database 1 12 for all of the users or folders, or some subset of the users or 
folders, such as all private folders, which reference the Jane Tarnoff contact and 
which have set the opt-in flag to illustrate this relationship. Upon running such a 
search, the user-contact reference routine 120 may then use the display routine 1 18 to 
display a screen such as that illustrated in Fig. 3 which shows the results of the search 
for the users who know the Jane Tarnoff contact. As illustrated in Fig. 3, five users 
(Ted Cruse, David Flynn, Kathryn Johnson, Ed Roberts and Barry Solomon) know or 
have referenced the Jane Tarnoff contact in their private folder and have set the opt-in 
flag to enable this relationship to be illustrated by the user-contact reference routine 
120. Only three of these users have placed a description in the description field 140 
for Jane Tarnoff. With the list of Fig. 3, the user who executed the user-contact 
reference routine 120 can next talk to any of the other users (Ted Cruse, David Flynn, 
etc.) about Jane Tarnoff to get more specific information about Jane Tarnoff, such as 
her likes and dislikes, etc. Likewise, the user who executed the user-contact reference 
routine 120 can determine which of the other users to talk to first based on the 
description or nature of the relationship displayed in the list of Fig. 3. 

[0039] Methods for enabling the user-contact reference routine 120 to determine 
which of the users of the relationship management system know which contacts will 
be now be described in more detail with respect to Figs. 4-14. Generally speaking, a 
set of user-contact pairs are stored within the database 1 12 and each of these user- 
contact pairs evidences the existence of a relationship of some kind between the 
contact indicated by the contact portion of the user-contact pair and the user indicated 
by the user portion of the user-contact pair. The contact portion may directly or 
indirectly indicate a particular contact and may be, for example, a contact ID. 
Likewise, the user portion of the user-contact pair may directly or indirectly indicate 
one or more particular-users. The user portion^may be, for example, a user ID or a 
folder ID. If the user portion is a folder ID, then the user associated with the user- 
contact pair may be one or more of the users having access rights to the folder 
specified by the folder ID. However, the user-contact pair may include any other type 
of information which indicates, either directly or indirectly, a relationship between a 
contact and a user. 

[0040] Referring to Fig. 4, the database 1 12 may include (store) a join table 150 
which may have a number of fields. The first field 152 (illustrated as the first column 
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of the table 100) is a contact- folder pair field in which a contact ID and a folder ID 
pair for every contact in every folder that is to be used in performing the 
determination of which users know a specified contact is listed. While the contact 
and folder IDs are illustrated in Fig. 4 as being in a single column or field, they would 
typically be stored in separate columns or fields within the database 112. In any 
event, there will be a separate contact- folder pair for each of the contacts illustrated in 
the Ed Roberts' folder of Fig. 2 where the contact ID changes but the folder ID 
remains the same (because all of these contacts are in the same folder). Of course, the 
same contact within different folders will produce contact-folder pairs having the 
same contact ID but having different folder IDs. For each contact-folder pair, an opt- 
in flag field 154 (the second column of the table 150) exists. If the opt-in flag is not 
set (O), then the user-contact reference routine 120 will not use the contact-folder pair 
in identifying which users know a specified contact and will not display this 
relationship in the results of the search performed by the user-contact reference 
routine 120. As indicated with respect to Fig. 2, the opt-in flag is set (X) by selecting 
or not selecting the box 138. Furthermore, each entry in the join table 150 includes a 
relationship description field 156 in which the user entered description of the 
relationship is stored. The description field 156 corresponds to the section 140 of Fig. 
2. Likewise, other fields may exist, such as a predetermined description field 158 
(storing a simple descriptor of the type of the relationship) and a relationship strength 
field 160 indicating the strength of the relationship, as described above. The join 
table 150, which may be created and used to specify which folders reference which 
contacts, is stored in the database 1 12 and is updated each time a contact is added to 
folder or deleted from a folder. Of course, the information stored in the fields 154, 
1 56, 158 and 160 may be changed by users at any time. 

[0041] When executing, the user-contact reference routine 120 may access the join 
table 150 and search for the contact ID in each of the contact- folder pairs within the 
contact-folder pair field(s) 152. Upon finding the contact ID, the routine 23 
determines the ID of the folder in the pair and uses this folder ID to identify the 
user(s) who has (have) a relationship with the contact. In particular, the users having 
access to the identified folder, or the primary user of the identified folder may be 
determined as the user having the relationship with the contact. If desired, the folder 
name may be used as the user having the relationship with the contact. In some cases, 
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the user contact reference routine 120 may only search for contacts in certain classes 
or types of folders, such as privately owned folders, to assure that there is a one-to- 
one user- to-contact relationship. However, this need not be the case and more than 
one user may be identified as the user having the relationship with the contact for 
each contact-folder pair. If the user-contact reference 120 is only used, for example, 
with private folders, the routine 120 determines the type of the folder (which is 
typically stored as an attribute of the folder in a folder table) and discards or dismisses 
contact-folder pairs in which the type of the folder is not a private folder. 

[0042] In any event, whenever the user-contact reference routine 120 identifies a 
contact folder pair for the particular contact and the folder is of the appropriate type, 
the routine 120 checks the status of the opt-in flag in the field 154 for that contact- 
folder pair. If the opt-in flag is set, then the relationship is illustrated to the user in a 
list or results screen, such as that of Fig. 3, which may identify the user(s) associated 
with the folder in the identified contact-folder pair. The information in the fields 156, 
158 and 160 may also be displayed to the user in the results screen. Of course, it will 
be understood that the opt-in flag can be set or not set to cause the relationship to be 
illustrated in the results screen and the opt-in flag could just as well be an opt-out flag, 
both of which are considered to be the same thing herein and will be described as an 
opt-in flag. 

[0043] In another embodiment, a separate table called a user-contact table could be 
created within the database 112 and used to enable the user-contact reference routine 
120 to operate. Referring now to Fig. 5, a user-contact table 170 includes a first 
column or field 172 which holds, for example, a contact ID and a user ID pair and 
columns or fields 174, 176, 178 and 180 which are the same as the fields 154, 156, 
158 and 160 of Fig. 4, namely, the opt-in flag field 174, the user defined description 
field 176, the preset relationship type field 178 and the relationship strength field 180. 
Again, while the contact and user IDs are illustrated in Fig. 5 as being in a single 
column or field, they would typically be stored in separate columns or fields within 
the database 1 12. In this case, each time a user performs some activity which 
references a contact, such as putting a contact within a folder to which the user has 
access, or performing some other function, such as requesting information about the 
contact, performing a search on the contact etc., the database access routine 1 16 may 
ask the user whether or not the user wants the relationship with the contact to be used 
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in the future in the user-contact reference function. If the user says yes, the user ID 
and contact ID may then be stored as a pair in the user-contact pair field 172, the opt- 
in flag can be set (or not set) and the associated relationship information such as the 
relationship description, the relationship type, and the relationship strength 
information may be provided by the user and stored in the user-contact table 170. 
This relationship information may, for example, be provided by the user using the 
screen 130 of Fig. 2 when the user adds a contact to a private folder or may be queried 
from the user when the user performs some other function to indicate that the user 
knows or has a relationship with a contact. A user-contact pair may also be deleted 
when a user removes a contact from a folder. If desired, however, the user may be 
prompted to see if the user wants to delete the user-contact pair from the table 170 
when a user removes a contact from a folder (or at other times) to thereby enable a 
user-contact pair to exist and be discovered by the user-contact reference routine 120 
even though the user may not have access rights to a folder referring to that contact. 
The user-contact table 170 of Fig. 5 enables the relationship management system to 
capture user-contact relationships even when a user does not place a contact within a 
folder to which the user has access or after a user has deleted a contact from that 
user's folder. 

[0044] Fig. 6 illustrates a folder table 190 which may be created and stored in the 
database 1 12 to, among other things, enhance the operation of the user-contact 
reference routine 120 described herein. The folder table 190 is a table within a 
standard data model and is illustrated as defining the type of attributes in the left-hand 
column, the type of data stored by the attributes in the middle column and whether the 
attributes are required fields (NOT NULL) or non-required fields (NULL) in the 
right-hand column. As illustrated in Fig. 6, the folder table 190 includes unique IDs 
or keys of DIRECTORY ID and DIR ECTOR Y_SCR_ID (above the line in the table) 
which may be used to provide a unique number or ID for each folder used by the 
relationship management system. Each folder also includes a number of attributes 
including a type attribute (DIR_TYP_ID) which may be a private type, a group type, 
etc., a name attribute (DIRECTOR Y_NM), a description attribute 
(DIRECTOR Y DESC), and an owner attribute (OVVNER_ID) which identifies the 
owner or user who has primary access to the folder. Each folder may also include 
auditing attributes, such as attributes which indicate the user who created the folder 
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(CREATEID), the date of creation (CRE ATEDT) , the last user to edit the folder 
(LASTEDITED), the name of the user who performed the last edit 
(LAST_EDIT_NM) and the last edit date (LAST EDIT DT). Of course, other 
attributes may be provided for other functions performed using the folder. One 
attribute however, illustrated in Fig. 6 as the SHAIIE_EXISTENCE_IND attribute, 
may be used to set a default value for the opt-in flag 154 of Fig. 4 or 174 of Fig. 5. 
Thus, the default value of the SHARE EXISTENCE IND attribute may be set on a 
folder basis and this value determines the default setting to which the opt-in flag 154 
or 174 will be set within the join table 150 or the user-contact table 170 for each user- 
contact pair created within the join table 150 or the user-contact table 170 for a 
particular folder. Of course, the value specified by the SHARE_EXISTENCE_IND 
attribute may be changed using, for example, the box 138 in the screen display of Fig. 
2. 

[0045] Referring now to Fig. 7, an example join table 192 and the attributes thereof 
are illustrated. In particular, the join table 192 includes unique keys defining the 
contact (LISTING_ID and LISTING_SRC_ID) and the folder (CONTAIN_DIR_ID 
and CONTAIN DIR SRC ID) pair. Each contact- folder pair includes additional 
attributes such as auditing attributes (the CREATE and LAST attributes as defined 
above) and other attributes not specifically needed to determine which users have a 
relationship with a particular contact. Likewise, each contact-folder pair includes an 
EXISTENCE ESTD attribute which stores the value of the opt-in flag for this contact- 
folder pair and an EXISTENCE_DESC attribute which stores the string defining the 
relationship description entered into the section 140 of the screen display 130 of Fig. 
2 for this contact- folder pair (which is a user-contact pair). Of course, each entry in 
the join table 192 could have other attributes used to store other types of relationship 
description information, or used for other purposes by the relationship management 
system, if so desired. 

[0046] Of course other methods of storing and determining relationships between 
users and contacts using tables in the database 112 may be used as well to enable the 
user-contact routine 120 to determine which users have a relationship of some kind 
with any particular contact. The user-contact routine 120, as described herein, 
enables the relationships between users of the relationship management system and 
any particular contact stored in the database associated with the system to be 



- 16- 



Patent 

Atty. Docket No. 29516/38346 

determined quickly and accurately because this information is automatically stored, 
created or deleted when a user references a contact or deletes a contact from a folder 
or otherwise indicates a relationship with a contact. Furthermore, because the 
relationship information is stored in and determined from tables, such as those used to 
perform other functions within the relationship management system, no one has to 
manually enter or update a user-contact reference list, which makes the relationship 
information determined by the user-contact reference routine 23 described herein 
more accurate and reliable. Still further, the opt-in flag enables a user to hide the fact 
that the user has a relationship with a particular contact, assuring privacy where 
needed or desired. Likewise, the relationship description, type and strength or other 
relationship description fields provide a user with more information about the 
relationships between users and any specified contact than that provided by a 
manually created list of user-contact relationships typically created by known 
systems. 

[0047] In another embodiment, the user-contact routine 120 accepts a designation 
of the target person from a user (e.g., Ed Roberts) and subsequently initiates a 
pathway determination, which will be described with respect to Fig. 8. As illustrated 
in Fig. 8, a screen display 200, which may be created by the display routine 1 18, is 
displayed to the user who has designated a desired target individual. In this illustrated 
example, Ms. Jane Tarnoff is the target individual. When a target individual is 
designated, the screen display 200 displays a person overview where the name of the 
contact is displayed in a first field 202. As illustrated, the first field 202 may also 
display information including business associations, title, phone numbers, an e-mail 
address, and a web site address for Jane Tarnoff. 

[0048] Additionally the screen display 200 includes a profile field 204 that allows 
the user to selectively view information about the target individual such as 
employment information (which is shown expanded in a field 204), educational 
information, contact information, etc. Further, a notes section 206 allows the user to 
view notations stored within the database 112 from other users (e.g., shown as "Firm 
Notes") or notations written by the particular user about the target person. The 
display routine 118 may also display on the screen display 200 a listing of related 
people, companies and organizations as illustrated in field 208. This field can be 
controlled to display co-workers of the user who know the target person, key 
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relationships between users of the database and the target individual, common 
company or organization affiliations of users and the target person, etc. 

[0049] Another field shown in Fig. 8 is an "Actions" field 210, which allows the 
user to select from a number of various functions. One of these functions is a "View 
Relationship Map" function labeled by reference number 212. The user (e.g., in the 
previous example, Ed Roberts or someone else having access to Ed Roberts 1 private 
folder) selects this function to plot relationship pathways or connections between the 
user and the designated target person. Thus, when a starting person, such as Ed 
Roberts or a user viewing the Ed Roberts' folder, wants to find relationship 
connections or pathways to the target individual, i.e., Jane Tarnoff, the starting person 
initiates plotting of a relationship connection via the function 212, which first causes 
the relationship management routine 1 10 to implement the user-contact reference 
routine 120 that searches the database 1 12 for all of the users or folders, or some 
subset of the users or folders, such as all private folders, that reference the target 
individual, as well as information stored in the database 112 about the target person. 
The routine then returns a list of found user-contact pairs to the interface 102 for use 
by the relationship pathway determination routine 122. 

[0050] Once the information is delivered by the user-contact reference routine 120 
to the relationship pathway determination routine 122, the routine 122 may link or 
intersect user-contact pairs such that any two adjacent entities in the determined 
pathway relationship is a user-contact pair. As an example, Fig. 9A illustrates a first 
level of pathway determination. A first group or list of contacts for Ed Roberts is 
returned as shown in column list 300. Here, a group of user-contact pairs is listed 
where the user, Ed Roberts is constant, and a particular number "n" of contacts (here 
shown as contacts "A" through "E") are shown. These contacts are typically persons 
at the same work organization as the user (e.g., people that Ed Roberts works with and 
are users of the database). Arrows 302 are illustrated to point out the user-contact 
pairs. For example, the user-contact pair of Ed Roberts (otherwise referred to as ER) 
and contact "A" is shown by arrow 302i, the user-contact pair ER-B by arrow 302 2 
and so on. The list 300 may also be assembled according to criteria other than simply 
other users of the database. For example, the contacts may be also be non-user 
contacts of Ed Roberts. 
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[0051] Similarly, the group of user-contact pairs associated with a target contact, 
e.g., Ms. Toby Adamson (otherwise referred to as TA), is illustrated by column list 
304, which lists users R, S, T, U and B as knowing or having some relationship or 
connection with TA. Hence, Fig. 9A illustrates user-contact pairs, such as R-TA 
shown by arrow 306 1, S-TA shown by arrow 306 2 and B-TA shown by arrow 306 n . 
The user-contact pairs 306 may be determined based on actual connections, potential 
connections or both. Examples of the relationship or connection criteria for 
determining potential connections include common work affiliations, organization 
affiliations and educational affiliations. 

[0052] Given the determined user-contact pairs, the relationship pathway 
determination routine 122 may then search for user-contact pairs of the lists 300 and 
304 that intersect or may be linked. In the example shown in Fig. 9A, a common 
user/contact "B" is found in both lists 300 and 304. Thus, the linking or pathway can 
be represented by ER-*B— >TA. From this pathway, it can be seen that adjacent 
entities (i.e., ER and B or B and TA) in the relationship pathway include respective 
ones of the user-contact pairs. This first level contact pathway corresponds 
essentially to the Who-Knows-Who™ feature described above because it tells Ed 
Roberts that "B" knows Toby Adamson. 

[0053] An example of a multiple linking or pathway, i.e., where three or more 
contact pairs are used to make a pathway determination, is illustrated in Fig. 9B. 
Such higher degrees of pathway linking may be performed when no first level 
pathway can be determined or when multiple pathways are desired. Additionally, the 
additional user-contact pairs may be determined by the routine 120 at one time or the 
routine 120 may be configured to perform additional searching after the first level 
pathways are found non-existent or a user requests further pathways. As shown in 
Fig. 9B, the column lists 300 and 304 of Ed Roberts 1 contacts and users having actual 
or potential connection to Toby Adamson are respectively shown similar to Fig. 9A. 
Additionally, however, the routine 122 then accesses further retrieved user-contact 
pairs for each of the contacts of Ed Roberts' who are users of the system; in this case 
users A, B and E being illustrated in table 309. Thus, column lists 310, 312 and 314 
illustrate A, B and Es' contacts stored in the database 1 12 for these users or, in other 
words, the user-contact pairs for each of these users, which are indicated by arrows 
316, 318 and 320, respectively. The routine 122 then plots intersections or pathways 
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between the user-contact pairs in the lists 316, 318 and 320 and the user-contact pairs 
of column list 304. An example of a plotted pathway 322 is shown including the 
following user-contact pairs: ER-A (pair 302 0, A-G (pair 316 2 ) and G-TA (pair 
306„.i), which form the pathway of ER-^A^G^TA. Again, as in the previous 
example, the adjacent entities in the pathway consist of user-contact pairs. 
[0054] As an example of yet further degrees of pathways, Fig. 9C illustrates a case 
where further intermediate users are required or desired for determining additional 
degrees of relationship pathways. As shown, the column lists 300 and 304 of Ed 
Roberts' contacts and users having actual or potential connections to Toby Adamson 
are respectively shown similar to Figs. 9A and 9B. Also, the further retrieved table 
309 of user-contact pairs for each of the contacts of Ed Roberts' who are users of the 
system is utilized. From the contact listings for each of the users in table 309, 
additional tables are formed for each of the system users in each of columns of user- 
contact pairs. As shown in Fig. 9C, one such table 324 is illustrated, wherein contacts 
stored for each of the users in A*s contact list 310 are accessed. As shown in table 
324, exemplary column lists for A's contacts F, G and H are shown in columns 326, 
328 and 330, respectively. The pathway determination routine 122 then checks to see 
if any intersections of the user-contact pairs in column list 326, 328 and 330, for 
example, intersect with the user-contact pairs 306 of column list 304. One such 
intersection is illustrated by reference number 332 showing that F and TA have a 
common contact/user R. Thus the plotted relationship pathway in this case consists of 
user-contact pairs ER-A (pair 302,), A-F (pair (316,), F-R (pair 334 3 ), and R-TA (pair 
306,). In other words, the relationship pathway is ER— »A— >F — »R— +T A, where 
adjacent entities in the pathway comprise a user-contact pair. 

[0055] As will be appreciated by those skilled in the art, the length of the 
relationship pathways' may include even longer strings of linkings. Nevertheless, it 
can also be appreciated that longer pathways illustrate weaker or more tenuous links 
between the starting person and target due to the higher number of intermediate 
persons. Such considerations may be programmed into the pathway determination 
routine 122 by limiting the lengths of the pathways to some predetermined maximum 
number of contact pairs. Additionally, when a user does not opt-in a contact, this 
contact may be proscribed from inclusion in a viable user-contact pair to be used by 
the pathway determination routine 122. 
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[0056J According to another example, the pathway determination routine 1 22 can 
also determine potential pathways based on commonalities between users of the 
system and the target person. The users of the system could include people in the 
starting person's folder, whether users of the database 1 12 or not, as well as all the 
users of the database 112. The potential pathways are then determined based on, for 
example, three categories or criteria. The first criterion is common companies or 
employers to which the target person and the database users or other persons in the 
starting person's folder were or are related. For example, the routine 122 determines 
that the target person and a contact person in the starting person's folder both worked 
for Motorola during a particular time period. Thus, a commonality exists that can be 
used by the starting person. A next criterion is common educational backgrounds. 
For example, the routine 122 will determine common colleges attended, for example, 
between the target individual and the database users or other persons in the starting 
person's folder. The third criterion is common organizational affiliations. Examples 
of such affiliations include boards of directors, charitable organizations, professional 
associations, etc. 

[0057] As mentioned above, upon running the relationship pathway determination 
routine 122, the relationship management system 110 may use the display routine 118 
to display a screen such as those illustrated in Figs. 10A and 10B, which show the 
results of the determined pathways between a starting person (e.g., Ed Roberts 
(appearing to the user as "Me")) and a target person (e.g., Toby Adamson). As 
illustrated in the example of Fig. 10A, the relationship pathway determination routine 
122, after determining users of the database who have connections to Toby Adamson, 
causes the display routine 1 18 to return a display screen 400 to the requesting user. 
As illustrated, the screen 400 displays a list 402 of those users of the database who are 
potential connections between the starting person 404 (labeled "Me") and the target 
person, such as Ms. Toby Adamson 406. With the list 402 illustrated in Fig. 10A, the 
starting person 404 who executed the relationship pathway determination routine 122, 
can then contact any of the listed users (e.g., Jane Tamoff, Craig Barret, Leslie 
Vadasz, etc.) about the target person, i.e., Toby Adamson, to get more specific 
information about the target person, such as for the purpose of making an introduction 
between the starting person and the target or simply contacting the starting person, 
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knowing that the starting person potentially has a connection to one or more of the 
users in the list 402. 

[0058] Another feature of the relationship determination routine 122 that is 
illustrated in Fig. 1 OA is a field 407 enabling the starting person to direct the routine 
122 to search for additional relationship pathways utilizing information from alumni 
or past employees of the firm where the starting person works or former users of the 
database 1 12. This feature may be helpful, for example, when the routine 122 returns 
little or no connections using current users or contact information stored in the 
database 112. 

[0059] Further, the starting person 404 has the option of expanding the particular 
linkings to view more detailed information concerning the potential connections 
between the target person and the users or other persons displayed in list 402. 
Specifically, a selection field 408 labeled as "Expand" allows the starting person the 
expand the information details as illustrated in Fig. 10A. When a user selects the 
expand field 408, the display routine 118 causes the viewable information to be 
expanded as illustrated in Fig. 10B. In this example, information concerning Jane 
Tamoff is displayed. As illustrated, information that is displayed is categorized into 
at least three different fields generally corresponding to the three criteria discussed 
previously. Thus, a first information field 410 illustrates employment or company 
affiliations common to the potential linking person (e.g., Jane Tamoff) and the target 
person (e.g., Toby Adamson). In the illustrated example, the information displayed in 
field 410 communicates that Jane Tarnoff is an employee of Intel Corporation, as well 
as a key contact for at least one user of the database, and that Toby Adamson was on 
the board of directors of Intel. 

[0060] A second information field 412 that is displayed and corresponding to the 
second criterion discussed previously is common educational affiliations. In the 
example of Fig. 10B, the information displayed indicates that both Jane Tarnoff and 
Toby Adamson attended Stanford University. Additional information may include, 
for example, degrees conferred and years attended, as illustrated. 
[0061 ] Another information field 4 1 4 illustrates common organization affiliations. 
In the example of Fig. 10B, information shows that both Jane Tarnoff and Toby 
Adamson are supporters of ALSAC-St. Jude Children's Research Hospital. 
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Additional information concerning the capacity of respective person's involvement 
may also be displayed as further illustrated in Fig. 10B. 

[0062] The order of persons appearing in the list 402 illustrated in Figs. 1 OA and 
10B also may be utilized to indicate links from the strongest to the weakest (displayed 
from top to bottom in this example), for example, the relative strengths of the plotted 
relationship connections. Thus, the starting person or user who initiated the 
relationship pathway determination routine 122 can determine which of the other 
users to talk to first based on this further information displayed by the order of list 
402. The displayed listing order is derived using a pathway weighting routine 124 
and a prioritization routine 126, as illustrated in Fig. 1, that may be called by the 
relationship determination routine 122. The routines 124 and 126 will be described 
further in relation to Figs. 1 1 and 12. 

[0063] The weighting routine 1 24, in particular, is used to determine a strength of 
each relationship pathway determined by the relationship pathway determination 
routine 122 by using the relationship strength information stored in the database 1 12 
regarding strengths of each of the user-contact pairs as well as accessing the 
information concerning common employment or company affiliations, educational 
affiliations and organizational affiliations. This retrieved information concerning the 
individual user pairs in a pathway is used by the weighting routine 124 to obtain an 
aggregate weight value according to a predetermined algorithm. In deriving the 
aggregate weight value, the algorithm may take into account factors such as the type 
of relationship (e.g., personal, family, social or business) for each user-contact pair, 
whether the relationship is current or a former relationship, the total number of user- 
contact pairs in the relationship pathway, the locations of the user-contact pair within 
the pathway (e.g., near the beginning, in the middle, or at the end), etc. to achieve a 
more accurate and qualitative correlation to the quantitative value computed. 
Furthermore, the weighting routine may assign higher importance to factors such as 
common workplace or organizational affiliations, while according factors such as 
common educational affiliations a lower importance. The returned cumulative, 
aggregate or average weight value may then be used to assign a quantitative value that 
approximates a qualitative measure of each determined relationship pathway. 
[0064] As examples of aggregate weightings, Fig. 1 1 illustrates three different 
relationship pathways 500 and 502, all between the same starting and target persons 
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(e.g., Ed Roberts and Toby Adamson). In pathway 500, including user-contact pairs 
ER-A and A-TA, the weighting routine 124 retrieves relationship strength data for 
each pair. Thus, for example, the relationship strength information stored for the 
relationship between Ed Roberts and contact A is a quantitative value of 3. Similarly, 
the relationship between user A and target contact Toby Adamson is 2. These 
quantitative strength values are input to the weighting algorithm of routine 124, which 
returns an aggregate value 5 for this relationship pathway, as an example. 
Alternatively, the weighting algorithm could determine an average, such as 2.5 in this 
particular example. It will also be appreciated by those skilled in the art that 
weightings may be similarly computed for pathways have more than one intermediate 
user between the starting person and target individual. 

[0065] As an alternative example, a relationship pathway 502 is illustrated that 
includes the same pairs ER-A and A-TA as pathway 500. However, different from 
the example of pathway 500, the routine 124 determines the strength of the pathway 
based on the criteria of organizational, workplace and educational affiliations. 
Furthermore, the pair A-TA is only considered in determining the strength of the 
pathway 502. Thus, as shown in this example, because A and Toby Adamson have 
two common connections of company and educational affiliations, these 
commonalities are used in computing the pathway strength. As illustrated, the 
common company affiliation is assigned a weight of five points. This point 
assignment is an arbitrary predetermination. That is, the database may be customized 
at set up by the database client to assign particular weightings as deemed important by 
the client. Moreover, the point assignments may be determined dependent on whether 
the connection is current or in the past. Thus, for example, the points assigned for a 
current or recent common employment affiliation could be five points, whereas a less 
recent common affiliation is only assigned two points. 

[0066] The example pathway 502 also shows that the existence of common 
educational affiliations between TA and A is also accorded a point value, e.g., one 
point as shown in Fig. 1 1 . Once all points are assigned, an aggregate sum of the point 
values may be used to assign an overall strength value to the pathway 502. This 
aggregate value is illustrated by the total sum of six points in Fig. 1 1 . 
[0067] Additionally, the weighting routine 1 24 may direct the display routine 1 1 8 
to provide a display indication of an aggregate weight for each pathway and, if 
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desired, respective relationship weights for each of the user-contact pairs in a 
pathway. 

[0068] For the purpose of determining the order that the list 402 is displayed to the 
user, the prioritization routine 126 may be used to prioritize the determined 
relationship pathways based, in part, on the weights determined by routine 124. As 
illustrated in Fig. 12, the weights of the determined pathways are input to routine 126, 
which outputs a listing from highest to lowest strength, for example. The example of 
Fig. 12 illustrates the listing displayed in Figs. 10A and 10B. 
[0069] Prioritization may be as simple as listing the pathways from highest to 
lowest aggregate strength values, thereby assigning highest priority to those pathways 
with the highest aggregate strength value. The routine 126, however, may also apply 
further factors to determine the highest priority to lowest priority pathways. For 
instance, if two pathways have the same aggregate strength rating, factors such as 
whether the relationships in the pathway are predominately business relationships or 
personal relationships may be considered to determine which of the two pathways 
would be given the higher priority listing. Also, for those pathways having the same 
strength ratings, the prioritization routine 126 may arbitrate between pathways by 
deeming the pathway having the highest single strength value as the strongest 
potential pathway. 

[0070] A method for enabling the pathway determination functionality of the 
relationship management system 1 10 is described with respect to the flow diagram of 
Fig. 1 3. As shown, the operation starts at block 702 when a user of the system 1 10 
initiates finding relationship pathways or connections by, for example, selecting field 
212 (e.g., "View Relationship Map") shown previously in Fig. 8. The user will either 
be prompted to enter a starting person, if the user is not the starting person, or simply 
be prompted to continue if the user is the starting person at block 704 as executed by 
the database access routine 116. At a block 704, the user enters or selects a target 
person, with whom the system 110 will determine relationship pathways from the 
starting person. The routine 1 16 then initiates a search request to the database 1 12 as 
indicated at block 706. Next, the database access routine 116 initiates retrieval of 
user-contact pairs for the starting person from that person/user's folder as shown at 
block 708. Additionally, the routine 116 retrieves user-contact pairs that have the 
target person as a contact, also shown at block 710. 
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[0071 ) Once user-contact pair data has been retrieved and assembled (e.g., by the 
user-contact reference routine 120), the relationship pathway determination routine 
122 plots pathways that link the starting person to the target person as indicated by 
block 712. Once one or more pathways have been determined, a query is made 
whether further pathways may be determined as indicated at decision block 714. If 
further pathways may be determined, flow loops back to block 712 to plot further 
pathways. 

[0072J Alternatively, if no more pathways are to be determined as found at block 
714, the flow proceeds to decision block 716. If the user desires more pathways, as 
initiated by a prompt to the user through the display routine 118, for example, the 
flow proceeds to block 718. At block 718 the database access routine is called to 
retrieve further degrees of user-contact pairs, e.g., user-contact pairs for all 
user/contacts of the starting person. The relationship pathway determination routine 
122 then plots further relationship pathways between the starting person and the target 
person using the additional user-contact pairs retrieved as shown in block 720. Flow 
then proceeds back to block 714, where a determination is once again made as to 
whether further pathways exist. The user is again prompted to determine if more 
pathways are desired at block 716. Alternatively, the determinations in blocks 714 
and 716 could be effected by an automatic process where the routine 122 is used to 
determine all possible pathways up to a predetermined number of user-contact pairs 
that may be used to plot a pathway. 

[0073] After no more pathways are desired, as determined at block 7 1 6, flow 
proceeds to block 722 where the pathway weighting routine 124 computes 
quantitative weights for each of the determined relationship pathways. Next, the 
pathway prioritization routine 126 determines a priority order in which to display the 
pathways to user as shown in block 724. Finally, after the priority order is 
determined, the display routine 1 18 is called to display a listing of the prioritized 
relationship pathways to user's terminal 102 as indicated at block 726. 
[0074] Methods for enabling the retrieving of the user-contact pair (block 708) to 
determine which of the users of the relationship management system know the 
starting person will be now be described in more detail with respect to Fig. 14. 
Generally speaking, as described above, a set of user-contact pairs is stored within the 
database 1 12 and each of these user-contact pairs evidences the existence of a 
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relationship of some kind between the contact indicated by the contact portion of the 
user-contact pair and the user indicated by the user portion of the user-contact pair. 
The contact portion may directly or indirectly indicate a particular contact and may 
be, for example, a contact ID. Likewise, the user portion of the user-contact pair may 
directly or indirectly indicate one or more particular users. The user portion may be, 
for example, a user ID or a folder ID. If the user portion is a folder ID, then the user 
associated with the user-contact pair may be one or more of the users having access 
rights to the folder specified by the folder ID. However, the user-contact pair may 
include any other type of information which indicates, either directly or indirectly, a 
relationship between a user and a contact. 

[0075] As shown in Fig. 14, an example of the retrieval of user-contact pairs is 
initiated when the database access routine 116 initiates retrieval of user-contact pairs 
of the starting person (block 708) at block 802. The database access routine 1 16 may 
initiate the search by searching the database 1 12 to retrieve all the user-contact pairs 
for the starting person from that person/user's folder at block 804. The retrieved user- 
contact pairs may be similar to a list of contacts within the database that are 
considered "my contacts" or contacts contained within the user's rolodex. The 
database access routine 1 16 may then initiate a search of the database 1 12 for contacts 
that work at the starting person's company at block 806. The company search may be 
based upon a company name stored with each contact in the database 1 12 and may 
include both employees and consultants. 

[0076] After a search for all contacts that work at the starting person's company, at 
block 808, the search may be expanded to include all former employees of the starting 
person's company. This may include any company alumni, such as former 
employees, retirees, or the like. In some embodiments, the system 100 may be 
programmed to search alumni at block 808 only is specifically requested, such as for 
example at block 716. To further supplement the user-contact pair search, the entire 
database 1 12 may be searched to return any contact for which the starting person may 
have any other relationship at block 810. This may include, for example, contacts that 
may be related to the starting person, or contacts that are serviced by the starting 
person (e.g., the starting person is the account manager). 

[0077] Once the retrieval of user-contact pairs of the starting person is complete, 
the database access routine 116 may merge the results of the various searches (blocks 
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804, 806, 808, 810) into a "List A" 812. "List A" 812 may then contain a list of 
contacts that the starting person probably knows. 

[0078] Turning now to Fig. 1 5, an example of the retrieval of user-contact pairs of 
the target person (block 710) is illustrated. As shown, the retrieval of the target 
person's user-contact pairs is initiated at block 820. The database access routine 116 
may then search the database 1 12 for a list of all companies, or other organizations, 
with which the target person has a relationship (block 822). This result set may 
include schools the target contact attended, companies for which they work, former 
companies for which they worked, charity, civic, and professional organizations with 
which they are associated, or the like. The results of the search at block 822 may be 
merged into a "List B" 824. 

[0079] The database access routine 1 1 6 may then a search of the database 1 1 2 for 
contacts that work at the target person's company at block 826. The company search 
may be similar to the search conducted at block 806 and may include both employees 
and consultants. The search may then be continued at block 828 to include all people 
who have a relationship with any of the companies connected with each of the 
contacts in "List B" 824. For example, the search at block 828 may include all 
contacts who are involved with the same charity organization, or alumni of the same 
university. 

[0080] The database access routine 1 1 6 may further search the database 1 1 2 for all 
contacts associated with the company of each contact in "List B" 824 at block 830. 
This search may include any current or former employee, any company alumni, 
retiree, or the like. The system 100 may then be programmed to search the database 
1 12 for all people in "List A" 812 that have a relationship with the target person at 
block 832. This search may include all "List A" contacts who have a contact 
relationship, such as being a relative, of the target person. 

[0081] Once the retrieval of user-contact pairs of the target person is complete, the 
database access routine 116 may merge the results of the various searches (e.g., 
blocks 822, 826, 828, 830, 832) into a "List C" 834. "List C" 834 may then contain a 
list of contacts that the target person probably knows. 

[0082] As illustrated in Fig. 16, an example of the plotting of pathways (block 712) 
is shown. As shown, the plotting of the pathways is initiated at block 840. The 
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system 100 may be programmed to determine the intersection of "List A" 812 and 
"List C" 834 at block 842. While it is understood that an instance of a single contact 
may exist multiple times in both "List A" 812 and "List C" 834, the intersection is 
preferably a distinct set of contacts. Once the intersection has been determined, at 
block 844, one or more reasons for inclusion is determined. The reason may be 
determined based upon the reason for inclusion in "List A" 812 and "List B" 824. For 
example, a contact reason may be that the contact was included in "List A" 812 
because the contact works at the same company as the starting person (block 806). 
The results of the list intersection may be merged into a "List D" 844. The "List D" 
844 may then be processed by the routine 1 10 at the block 714 as described in detail 
above. 

[0083] Although the routine 110, including the user-contact reference routine and 
the visibility checking routine described herein are preferably implemented in 
software stored in, for example, a memory of a user workstation or user interface, 
these routines may alternatively or additionally be implemented in hardware, 
firmware, etc., as desired. If implemented in software, the routines may be stored in 
any computer readable memory such as on a magnetic disk, a laser disk, an optical 
disk or other storage medium, in a RAM or ROM of a computer, user interface, 
workstation or other processing device. Likewise, this software may be delivered to a 
user or to a processing device via any known or desired delivery method including, 
for example, over a communication channel such as a telephone line, the Internet, etc. 
[0084] While the present invention has been described with reference to specific 
examples, which are intended to be illustrative only and not to be limiting of the 
invention, it will be apparent to those of ordinary skill in the art that changes, 
additions or deletions may be made to the disclosed embodiments without departing 
from the spirit and scope of the invention. 
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